WP管理者必見！AWSで構築する新スケーラブルなWordPress構成〜CloudFront as Reverse Proxy

大瀧隆太

2013.10.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ども、大瀧です。LINE砲やネットニュース、テレビでの紹介などに備えるべく日々の負荷対策に悩めるWordPress管理者のみなさん、朗報です！
WordPressの負荷対策にはいろいろな方法がありますが、その中でも既存WordPressへの影響が小さい、新しい負荷対策！その名もCloudFront as Reverse Proxy構成が昨日できるようになりました！(参考:弊社横田のブログ記事)

CloudFront as Reverse Proxy構成とは

CloudFront as Reverse Proxy構成は、クライアントのアクセス先をWordPressを実行するWebサーバーの代わりにエッジロケーションというCloudFrontのキャッシュサーバーに向け、CloudFrontをリバースプロキシとして利用する構成です。CloudFrontはAWSのサービスの一つで、従量課金で利用できるCDN(Contents Delivery Network)サービスです。以下に構成図を示します。

以前より、WordPressのプラグインを利用してCloudFrontと連携する方法(参考:弊社野中のブログ記事)がありましたが、リバースプロキシとして構成するところが新しいポイントです。

CloudFrontとELBの比較

AWSに詳しい方であれば、AWSにはELB(Elastic Load Balancing)がリバースプロキシで使えるじゃないか！と思うかもしれません。CloudFrontはELBにはない以下の機能によって、ELBよりも更に大規模なアクセス集中に耐えることができます。

機能名	CloudFront	ELB
キャッシュ機能	◎ 世界中にあるAmazonのデータセンター(エッジロケーション)のキャッシュサーバーにデータをキャッシュすることで、高負荷に耐える高速なレスポンスを実現！	× なし。リクエストは全てWebサーバーに転送されます。
エラーページ機能	◎ 404(Not Found)や500(Internal Server Error)などのエラー発生時に、別のWebサーバーにあるエラーページをレスポンスとして返送できます。これにより、 WordPressのWebサーバーが不調なときも安心！	○ Route 53というDNSサービスと組み合わせてエラーページを返すことができますが、DNSフェイルオーバーのため切り替わるまでのタイムラグがあります。

ちなみに、本来CloudFrontとELBは取捨選択するものではなく、両方を使うことでお互いの機能を補完することができます。今回のCloudFront as Reverse Proxy構成でも、Webサーバーの手前にELBを組み合わせることが可能です。

それでは、それぞれの機能について少し詳しく見ていきます。

CloudFrontのキャッシュ機能

CloudFrontの最低限の用語をここで押さえておきます。CloudFrontでは、元のコンテンツを持つWebサーバーをオリジン、オリジンへの振り分けルールをビヘイビアと呼びます。CloudFrontによるキャッシュ動作の流れを以下に示します。

初回アクセス

クライアントがCloudFrontのキャッシュサーバー(エッジロケーション)にアクセス
キャッシュサーバーは、ビヘイビアを確認しオリジン(WordPressのWebサーバー)にアクセス
オリジン(WordPressのWebサーバー)は、ブログ記事データなどをデータベースから、画像ファイルやCSSファイルなどをディスクから取得し、キャッシュサーバーに返送
キャッシュサーバーは各ファイルをクライアントに返送しつつ、GETリクエスト分をキャッシュに保存

2回目以降のアクセス

クライアントがCloudFrontのキャッシュサーバー(エッジロケーション)にアクセス
キャッシュサーバーはGETリクエストであればキャッシュをクライアントに返送、POSTリクエストなどの場合は初回と同様にオリジンから取得

2回目以降のアクセスはキャッシュサーバーがクライアントに直接返答するため、オリジンへのアクセス数を減らし、Webサーバーの負荷を大きく減らす効果があります。CloudFrontのキャッシュサーバーは、大規模Webサイトで十分実績のある非常にスケーラブルな構成になっているため、キャッシュサーバー自体の負荷を心配する必要はありません。

CloudFrontのエラーページ機能

CloudFrontには、オリジンへのコンテンツリクエスト時にオリジンからエラーレスポンスが返ってきた際の設定として、エラーページとエラーレスポンスを選択することができます。WordPressのWebサーバーとは別のWebサーバーを追加のオリジンとして登録し、エラーページのデータとして指定することができます。

これにより、万が一WordPressのWebサーバーがアクセス過多で不調になった場合も、Sorryページを表示することができます。また、エラーページ用に登録するWebサーバーにはAWSのストレージサービスのS3を指定することもできるので、実際にはWebサーバーを別途用意する必要もありません。

では、実際に構築してみます。

構成手順

想定する読者: AWS EC2の基本操作(キーペアの作成、EC2インスタンスの作成、SSHログイン)ができる方。AWSの操作がよくわからない方は、本ブログのEC2関連エントリーや、書籍(Amazon Web Services クラウドデザインパターン実装ガイド)などをご覧ください。

1. WordPressをホストするWebサーバーの構築

　WordPressをホストするWebサーバーを作成します。今回はAWS EC2インスタンスを使用しますが、他のクラウド環境やホスティング、オンプレミスのサーバーでも構いません。一から作るのも手間なので、今回はAmazonが公開しているCloudFormationテンプレートを利用します。

1-1. キーペアの作成

EC2インスタンスにSSHでログインするためのキーペアを用意していなければ、作成しておきます。

1-2. CloudFormationスタックの作成

以下のページから[オープンソースアプリケーション] - [WordPressは...]の部分を探し、「単一 EC2 インスタンスとローカル MySQL データベース」の右にある[Launch Stack]ボタンをクリックします。AWS Management ConsoleのCloudFormationスタック作成画面に切り替わります。ちなみに、他のリンクからデータベースとしてRDSを使用するスタック、ELBとRDSを使用するスタックを選択しても構いません。CloudFrontが動作します。

AWS CloudFormation Templates - Asia Pacific (Tokyo) region

最初の画面は変更せず[Continue]をクリックします。

次の画面では以下を設定します。

DBRootPassword : MySQLのrootユーザーのパスワードです。特に制限はないので任意のパスワードを入力します。
KeyName : 手順1-1で用意したキーペア名を入力します(otaki-kp1は私が作成したものです)。
InstanceType : 無料枠で収めたい場合は、t1.microで構いません。

あとは、[Continue]を3回ほどクリックし、CloudFormationのスタック作成を開始します。作成したスタック「WordPressSample」が[CREATE_COMPLETE]になるまで待ちましょう。

1-3. CloudFormationスタックの確認

[CREATE_COMPLETE]になったら、[Outputs]タブをクリックし、[WebSiteURL]の値(EC2インスタンスのホスト名を含む、WordPressのURL)を控えておきます。

2. CloudFrontの構成

AWS Management ConsoleのCloudFrontの画面に切り替えます。画面上方の[Create Distribution]をクリックします。

[Web]が選択されていることを確認し、[Continue]をクリックします

CloudFrontの設定として以下を入力し、画面を下にスクロールします。

1. Origin Domain Name: キャッシュサーバーがコンテンツを取得する、オリジンを指定します。先ほどの手順1-3で確認したURLのうち、EC2インスタンスのホスト名ec2-XX-XX-XX-XX.ap-northeast-1.compute.amazonaws.comを入力します。http://や末尾の/は不要です。ELBを組み合わせる場合にはELBの[DNS Name]、ホスティングやオンプレミスのサーバーも同様にDNS名などを入力します。
2. Origin Protocol Policy: HTTPS(SSL)をサポートするために、[Match Viewer]を選択します。HTTPのみで動作させる場合は[HTTP Only]のままで構いません。今回の検証環境ではWebサーバーがHTTPS:443ポートをListenしていないため、https://でアクセスするとエラーになります。
3. Allowed HTTP Methods: これが、今回のキモです！ [GET, HEAD, PUT, POST, PATCH, DELETE, OPTIONS]を選択します。こうすることで、POSTリクエストなどをオリジンに転送するようになります。

画面を下にスクロールしたら、続いて以下を入力します。

4. Forward Cookies: Cookieをオリジンに渡すために、[All]を選択します。
5. Forward Query Strings: クエリ文字列をオリジンに渡すために、[Yes]を選択します。
6. Price Class: デフォルトでは、全てのエッジロケーションを使用するようになっていますが、適宜エッジロケーションを減らすことも可能です。今回はそのままにしておきます。
7. Alternative Domain Names(CNAMEs): 本番環境では独自ドメインを使用することになるため、そのドメイン名を入力します。その場合は、別途DNSのCNAMEレコードにCloudFrontのDomain Name(後述)を設定します。今回は空のままにします。
8. SSL Certificate: 独自ドメインを使用し、かつHTTPS(SSL)を使用する場合は、あらかじめSSL証明書をセットすることで独自SSL証明書を選択できます。具体的な手順は弊社都元のブログ記事を参照ください。今回は既定値(*.cloudfront.netの証明書)のままにします。

画面下部の[Create Distribution]で構築が開始されます。[State]列が[Deployed]になるまで待ち、[Distribution Settings]ボタンをクリックします。

[General]タブの[Domain Name]を確認します。これが、CloudFrontのアクセス先キャッシュサーバーのホスト名(<ランダム文字列>.cloudfront.net)になります。

3. WordPressの構成

手順1-3の[WebSiteURL]に、WebブラウザからアクセスするとWordPressの初期構成画面が表示されます。任意の値を入力し、WordPressの初期構成を完了します。

WordPressの管理画面にログインし、[Settings] - [Genral](全般設定)をクリックします。設定の[WordPress Address(URL)]と[Site Address(URL)]を、EC2のホスト名からCloudFrontのホスト名に変更します(http://<CloudFrontの[Domain Name]>/wordpress)。独自ドメインの場合は、CloudFrontの[Domain Name]を独自ドメインにします。

[Save Changes]ボタンをクリックして完了です。上記URL(http://<CloudFrontの[Domain Name]>/wordpress)にアクセスし、WordPressの動作を確認します。

動きました！記事のコメントなども試していただき、POSTリクエストが正しく処理されることも確認してみましょう。

構成時の注意点

クエリ文字列、Cookieはスルーさせる: 上記手順の通り、CloudFrontにはクエリ文字列およびCookieをスルーするかどうかを設定する項目があります。WordPressを正常に動作させるためにはそれぞれを必要なため、スルーするよう設定します。
POSTはキャッシュされない: キャッシュ機能の部分で、CloudFrontはGETリクエスト分をキャッシュするとありました。一方POSTリクエストはキャッシュせず毎回Webサーバーにリクエストすることになるため、WordPressの記事の書き込みや記事検索の処理能力は、Webサーバーおよびデータベースの性能に依存します。Webサーバーおよびデータベースのパフォーマンス管理が全く不要になるわけではないことに注意してください。今回の構成は、WordPressの記事や画像ファイルなどへのGETリクエストが集中するケースで効果を発揮します！
キャッシュは一定時間保持される: CloudFrontは、一度キャッシュしたコンテンツを一定時間保持するようになっています。ただ、誤って記事をアップしてしまったり、不適切な内容がコンテンツに含まれる場合も、キャッシュが保持されてしまうことに注意する必要があります。
独自SSL証明書を検討する: 本番環境であれば、/wp-admin以下はHTTPS対応させたいところだと思います。その場合、独自ドメインとの組み合わせで独自SSL証明書の準備と事前設定(&費用)が必要になるので注意しましょう。
動かないこともある...かも。: WordPressの主要な動作は試してみましたが、機能やプラグインによってはうまく動作しない場合もあるかもしれません。この記事のコメント欄やお手持ちのブログなどでの情報共有を歓迎します！